Vision to Value: How to Structure Tech Companies to Deliver Great Products by Gomes de Abreu Luis

Author:Gomes de Abreu, Luis [Gomes de Abreu, Luis]
Language: eng
Format: epub
Published: 2019-10-16T16:00:00+00:00

Working with team dependencies

As you design teams, you are working to put the conditions in place to increase productivity, to develop new features, or to deliver more and more quickly. Unfortunately, during real-life implementation, new teams actually slow processes down. Why?

Team dependencies are a near-invisible force that block work by slowing down each team's ability to continue work. Sometimes, when designing teams, you know that one team needs something from another. In other cases, dependencies are less visible, but they still exist. These dependencies force one stakeholder to wait on another in order to continue work, which will slow or even halt productivity.

Direct dependencies are visible and are typically translated to direct software or work-output dependencies. For example, a front-end team needs a back-end team to develop a certain feature in order to deploy a new User Interface. Or, a front-end team needs a DevOps team to deploy a certain infrastructure.

Dependencies of this nature create bottlenecks where one team is waiting on another. However, Product Owners and Scrum Masters can quickly align work and keep teams productive. In the case of very large products, a Scrum of Scrums, where teams get together and align everyone, will be necessary. You also need chapters to align experts, so that everyone is on the same page across squads and teams.

It's also important to pay attention to recurring dependencies. Here, you may want to redesign teams and distribute responsibilities to reduce interdependencies, which will slow work over time, even when managed correctly. Teams should have as much autonomy as possible so they can work without creating overhead to constantly align work with interdependent teams. Restructuring team modules, scopes, or responsibilities into more of a DevOps mindset where teams are developing while handling operations and servers will minimize work dependencies.

Strategy Tip: Adjust teams’ scope and responsibilities to avoid recurrent dependencies.

Indirect dependencies are less common than direct dependencies, but also more difficult to spot. Here, teams are waiting on the work or output of another team, but in a way that is not directly linked to that team's output.

How does that work? Let's say you have a team introducing a new technology that will enable other teams to develop their own modules in a better way. Existing teams must decide whether to continue maintaining the old modules or migrate to the new technology. Customers keep asking for fixes and small improvements on the existing modules. But, is it worthwhile for the team to invest in something that is in the process of being redeveloped? When is it worthwhile to stop? Here, the team handling maintenance will linger in a sort of waiting state, able to continue work but uncertain if they should. They are, in essence, waiting on the team to finish introducing the new technology so their work continues to add value.

This problem is exacerbated when teams developing new infrastructure or technology are unaware of stakeholders waiting on their work. These types of indirect dependencies are difficult to detect and will have a big impact on productivity.

Download

Copyright Disclaimer:
This site does not store any files on its server. We only index and link to content provided by other sites. Please contact the content providers to delete copyright contents if any and email us, we'll remove relevant links or contents immediately.